You want to revitalize a dying, inactive free software project. How do you proceed?

1. You write code, contribute, get involved in the community, get in touch with the previous developer(s) to try and join the team or take over the project. Failing that, you fork the project, because this is how free software works after all. Then, once you ve got something to show, you start talking about it;
2. You set up a new forum, brag about it on the old one, arrange with the previous lead developer to make sure you can use the name and logo, then open a twitter account so users can follow the new forum s setup process minute by minute.

There s this saying about opensource/free software that says the logo and about box are the very first (and only) things that work in new/young projects (and sometimes that s also true for more mature projects, as we all come to know). Choice 2 above is the About Box 2.0. Unfortunately, that s the way a handful of people choose to revitalize mt-daapd/Firefly Media Server. Of course, not one among them can code or has actually got a clue about the current codebase. FAIL of epic proportions. Facepalm.

pommed v1.28 is a minor update adding support for the MacBookPro5,3.

did FAI switch to that stinking pile of shit known as live-initramfs? Things that were possible before aren t possible anymore due to the extreme brokenness of live-initramfs. Nothing that can t be fixed by some heavy-handed patching here and there, but what a waste of time. Not happy. Hammer time.

Joerg, The patch you submitted has 0 chance of getting applied, and you know it. It s nothing more than a bad joke. The best solution for this issue is most probably to provide a xserver-xorg-nohal package that is a duplicate of xserver-xorg minus the HAL dependency.

Don t like HAL? X.org now forces it upon you via xserver-xorg. #515214, currently wishlist/wontfix.

From the Bits from the Debian Installer team mail to d-d-a:

It has been decided that, in order to not slow down the development processes, D-I SVN should be branched when the work on preparing a release starts. Even if SVN doesn t make the process very easy, changing the VCS we use is currently not an option we prefer.

SVN, branching, d-i. There s no word to describe how painful it is to work on d-i using SVN. d-i is big, SVN is slow in about everything it does. Now add branches to the mix. That mail left me very disappointed; first because I thought switching to git was sort-of planned for after the release of Lenny, and now it s off the table, second because some things in this mail are just wrong. Oh well. No d-i for me, I guess, then.

I ve just released a maintenance release of pommed. Nothing new under the sun in this one:

• support for the new mini external keyboard,
• the keyboard backlight idle timer now only takes keystrokes on the built-in keyboard into account,
• move away from using /dev/mem to access PCI memory, use sysfs resource files instead.

There are a couple of ideas floating around, we ll see if any one of those lands into a future release.

So, Kodak announced the availability of Linux drivers for some of its scanners, together with a frontend application. While the effort is laudable, they re not quite there yet. Let s have a look. First of all, and contrary to what a few people believe after reading the press release, the drivers themselves aren t OpenSource, let alone Free Software. They re all proprietary; read better, the press release clearly mentions that only the frontend application is GPLv2. Now let s look at what Kodak offers in its drivers packages. I ve downloaded LinuxSoftware_i1200_v3.5.tar.gz from the Kodak website, these are the drivers for the Kodak i1200 series. The archive contains a set of RPM packages, one Debian package corresponding to one of the RPM packages, and a setup script. One of the packages contains the OpenUSB library, which is released under the LGPL; sources aren t there, I haven t asked for the sources, don t plan on doing so, and am not implying anything regarding license compliance whatsoever. I ll note that I haven t seen any written offer for the sources, though, be it in the archive (there s not even a README in there) or on the website. So, although Ubuntu is listed as supported, we can say that no Debian packages are provided. The setup script actually relies on alien to convert them if it thinks it s running on a Debian-based system, which is determined by the availability of dpkg in the PATH. Using alien is far from ideal. The packages ship libraries and components under /usr/lib, /usr/local/lib and even /opt, pretty randomly it seems. Let s repeat here that /usr/local and /opt are strictly reserved for the local administrator and packages must not install anything here. There are other oddities in the paths used by the software stack, like /var/kodak. It looks like the SANE backend is only a bridge to Kodak s TWAIN data source, so you d actually need the whole stack to use it. All in all, Kodak does no better, I d even venture to say it does worse, than Epson (Avasys). At least part of Epson s backend is Free Software, even if it relies on proprietary libraries for some scanners, though unfortunately most if not all of the recent ones. I also have to mention that Epson is offering both RPM and Debian packages, and by that I mean proper Debian packages. Kodak are far from that, even the RPM aren t that great (I think the RPM packages even lack dependency information, based on what I ve read in the setup script, though I haven t checked). What Kodak offers here is a GPL frontend for TWAIN that not many people will be using, while keeping the drivers proprietary. Unfortunately their SANE backend isn t a backend so to speak, and even if it was OpenSource it d still rely on the rest of the TWAIN software stack. So, in a nutshell, while I m very happy to see yet another vendor go down the road of Linux support for its products, I am immensely disappointed by the proprietary nature of the drivers and the low quality of the packages. I was, of course, investigating the drivers to possibly package them for Debian; as you ve probably understood, it s not possible, both technically and legally. And I kept a little gem from the setup script for the end:

# We need to create a link for the libdbus-1 requirement for openusb,
# but only on Fedora.
if [ -f /etc/fedora-release ]; then
    ln -s /lib/libdbus-1.so.3 /lib/libdbus-1.so.2 2>> /dev/null
fi

As we all know, sonames and soversions are useless and they just keep getting in the way. Duh.

I ve been doing some code lately, fixing things here and there, and over the last few days gave mt-daapd some attention. First, I was reported a segfault of mt-daapd when reloading web pages too fast. Surprisingly, it turned out to be a stupid omission in a simple routine and it is hard to hit without disabling the cache in the browser. Now, I just fixed something that s been bugging me for a while: mt-daapd did not handle Avahi daemon restarts, leading to mt-daapd becoming invisible to clients relying on mDNS until you restarted it. And, wow, that went a bit further than expected. As I expected, the simple piece of code needed to handle that wasn t there. But still it did not work, as it turns out the event loop for the Avahi polling wasn t being run. Replace stupid code reinventing the wheel by the Avahi-provided wheel and there, it works. But not when run as a daemon (aka foreground only). Well yes, starting the thread before daemonizing isn t going to work well, so fix that. EPIC WIN \o/ As mt-daapd s upstream is not active anymore I m accumulating fixes for mt-daapd in the Debian package, to the point I m starting to consider setting up a git repository somewhere with those fixes and possibly some more code rework if I feel like it.

I ve migrated pommed to git yesterday. The public URLs for the git repository are: git://git.debian.org/git/pommed/pommed.git
http://git.debian.org/git/pommed/pommed.git The SVN repository will disappear shortly.

How not to start your day, from the all-hardware-sucks department. For years, I ve been struggling to keep my machines quiet. I ve miserably failed for years, and pretty much gave up once I realised that the quiet parts I was looking for just did not exist. Last year, I finally found what I was looking for:

• big, heavy, quiet case from Chieftec (with room for 8 HDD and their own dedicated 90mm fans (up to 3) and room for 2 120mm case fans);
• ber-engineered fans from Noctua (finally some guys took a shot at engineering fans, happiness \o/);
• fanless (except for the emergency fan) PSU from Antec (Phantom 500).

I ve been very happy with this hardware for both my workstation and my filer. Well, until today. No need to mention that this hardware is not exactly cheap, but the price is right for the quality. So, wake up today, do random things, grab my TomTom, unplug it from the workstation it s sucking its power from, do things, plug it back in the USB port so it won t draw its battery. This is how it went:

• plug TomTom into USB port;
• notice the LED is blinking, and it should not;
• erupt a mental WTF? and simultaneously hear *clac* *pffzziiouuuu*;
• unplug TomTom;
• replug TomTom, notice the LED is blinking again;
• look at the machine, notice it s gone down;
• check the PSU and erupt a verbal WTF?! noticing the LED on the PSU is not lit.

Check machine temp, PSU temp, attempt to restart PSU, check UPS, check cables, replace power cable and bypass UPS. Admit defeat for this round and accept the PSU as dead. Pull out the machine, rip out the fscking damn PSU. Grab the tools, crack the PSU open. Notice bulging and leaking capacitors. Yes, this PSU is anything but cheap, yet it uses el-cheapo chinese capacitors. Antec, you suck, big time. For the past decade everybody in the industry has known that el-cheapo chinese capacitors manufactured after 1999 are total crap, using an electrolyte that isn t actually one because its formula was stolen by industrial spies who got totally PWNED and ended up stealing a bad formula. (If you need a reference, google for singing capacitors . Note that singing capacitors can also happen with good parts used in a crappy electronic design. Like that 100 Mbps D-Link switch over there, or that Sony-Ericsson mobile phone charger. Hmm. Not everybody can hear it, I do.) A healthy, young capacitor should not bulge nor leak. A capacitor that leaks, bulges or sings is a crappy capacitor and needs to be replaced with a quality part ASAP. I ve been routinely replacing such capacitors on my older motherboards (manufactured between 1999 and 2001) in the past years. I ve not had the problem in ANY of my el-cheapo PSU, and did not replace any capacitor in any of them to date. Fortunately, the machine did not suffer any further damage, nor did the TomTom. Everything is up and running again with a spare PSU. I m now going to replace the fscking capacitors on this PSU, replace the fuse, probably R&R a couple of high-voltage transistors too (they have a tendency to fry before the fuse blows out) and get it back up and running. Then I ll do the same with the other PSU in the filer, because that machine has 8 disks attached, so draws more power and hence is much more vulnerable. Fuck you Antec.

Two fixes in this release, let s start with the more important one :) The DBus configuration file shipped with pommed now explicitly allows method calls to org.pommed, which is needed with the newer versions of DBus where the default configuration on the system bus has been made more strict to close a security hole. If the pommed clients stopped working for you after a DBus update, replace /etc/dbus-1/system.d/pommed.conf by the dbus-policy.conf file shipped with pommed. Second fix is related to the Apple wireless (Bluetooth) keyboard, which previous versions of pommed would recognize just fine but reject because it exposes a type of events usually indicative of a mouse (and pommed doesn t listen to mouse devices). This is now fixed for this particular keyboard, so pommed will react to the hotkeys on this keyboard too. For the complete list of changes, see the ChangeLog file in the source distribution. Comments at the usual address :)

pommed 1.24 is out; this is a maintenance release addressing the HID changes in the 2.6.28 kernel. HID quirks have been split out into hardware/vendor-specific submodules; consequently the sysfs path for the fnmode parameter changed as it s now handled by the hid_apple module and that needed to be accounted for. No rush if you re running an older kernel :)

David, I m not saying it lightly: the end goal is censorship, no matter how nicely you try to put it. The goal is to discourage people from posting. They call it peer pressure , which is nothing else but the politically correct equivalent expression for intimidation . The end result is censorship. The idea of censoring the mailing lists has actually been mentioned very clearly in the recent discussions on -devel, and I never thought it would go past that, but it s actually happening. By the way, this could actually morph into a shitty karma system that wouldn t let you post past your monthly allowance and credit earned . How s that for you? You refer to those +1/-1 mails; I find them silly, annoying, useless and a waste of bandwidth and CPU time. That used to be called a me too and generally despised and frowned upon. If you actually want to score posts or posters, get a decent MUA and set up its scoring system the way you like. But keep that to yourself. As Aigars told, there are mail to web forum gateways (more like rendering engines for a mail archive, actually) that will present mails to a list in a crappy web forum of some sort that will come with all kind of crap like scoring, karma and whatever. There s an essential difference between web forums and our mailing lists, though: forums of this kind use nicknames all over the place, our mailing lists use real names. There are privacy issues involved, and I m not giving up on that, either. You want to stop flamewars? Stop replying, especially to tell how intolerable it is and other shit. Just let the damn thing die already. Funny how the well-meaning people are feeling harassed on the mailing lists when they, themselves, are harassing people they disagree with. We don t all have the same views, culture etc. We re not all friends, and we probably never will be. Guess what? It s OK! Get over it and work with each other, because that is what we are here for. If you (general) can t get over it, I m afraid this Project is not the appropriate place for you. Imposing a monoculture of politically correct crap is not an answer to the perceived problems .

Dear Julien, that proposal is not about censoring mails sent in by people. Think to it as that "karma" thing many sites have. And yes, I'm one of those in favour of such project. I'm a free software,speech guy, but just hate all the flames seen lately on -devel. We must find a way to stop that, or at least to control it. Again, it's not censorship, as I read it, all messages would go in. Citing:

I have also seen opinions that other "obvious" ways of addressing the issue,
such as moderation of the lists or a new organizational entity, which
would act as a list watchdog, is not the way to go, as it adds yet
another layer of bureacracy and raises the usual questions of choosing
the "right" people for the privileged position.

It's just an alternative way of expressing opinions about a mail. Consider it as those "+1"/"-1" mails that you can often see.

I have been positively surprised to find out that some people are taking seriously the fact that some people are being put off from actively participating in Debian s discussions because doing so would lead to offensive behaviour and personal attacks, and to try to find a solution to the fact that a very vocal minority is dominating the silent majority. Of course, some people are happy with the statu quo and strongly opposes to changing anything in that direction, not very surprisingly. The part about I m really starting to think that this Project could do a lot better without some people is crystal clear and needs no comments. I m not really sure that the current social environment can be fixed just with technical measures. Another proposal talks about some mailing lists extracted from the official ones but with the offending comments filtered out. I must confess that I find this idea very interesting and that I might think about rejoining such a list. Of course, technical details on how to properly and effectively implement any of this methods, or even a mixed one, can be very tricky.

This proposal leaves me speechless. The replies even more. The sole fact that there are positive replies kills me. I m really starting to think that this Project could do a lot better without some people. Now if you ll excuse me for a sec, I have a urgent need to vomit. Reality check, people. Get back on the ground.

Christian notes, and rightly so, how much this vote sucks, for various reasons. There are too many viable options (as far as releasing Lenny is concerned) and that makes it tricky to vote in a useful way. And Christian got bitten by it: do not vote by ranking all options 1 to 7, or this vote will end up being our most EPIC FAIL to date. With that many options, the votes will end up diluted and who knows what the result will be. For this vote to succeed and be meaningful, it s pretty much required to rank several options equally. That is, and provided it matches your views, ranking the Let s release Lenny and give the finger to the zealots options at the same level. Be careful when voting on this one. IT S A TRAP.

pommed v1.23 is out, with full support for the late 2008 laptops. The LCD backlight inner workings got figured out finally, but there s a catch: the backlight won t react to the settings when running X11 with the proprietary nVidia drivers on the MacBook5,1 and the MacBookAir2,1. It works fine on the MacBookPro5,1 and it works fine on all three machines with the opensource nouveau driver. Switching to the console before setting the backlight and then back to X does work as a workaround. So there s something up with the proprietary nVidia driver, and my uneducated guess is that the MacBook Pro may somehow be exempt from the issue due to its dual GPU config. I ve also switched the nVidia machines to using the generic sysfs backlight driver in pommed. This driver has been there for some time for the PowerPC machines, so now it s part of the generic pommed code. You need the mbp_nvidia_bl driver in your kernel for this to work. Don t panic! If you don t have it, pommed will fall back to the native driver (nv8600mgt) and everything will work just as before. Pommed will tell you if it has to fall back to the native driver, so check your logs if you want to know. This release of pommed needs testing on all nVidia machines: MacBookPro3,1, MacBookPro4,1, MacBookPro5,1, MacBook5,1 and MacBookAir2,1. If anything doesn t work, tell me about it and I ll fix it.

I’ve just released pommed v1.22, which has been collecting improvements and reworks over the past few weeks; this release also adds partial support for the Late 2008 laptops. Partial support means the LCD backlight is not supported yet. The method for controlling the backlight has to be figured out; if you hear of anything, let me know. You’ll need a recent kernel for full support on these machines, which means either a late 2.6.28-rc or possibly an early 2.6.29-rc. It all depends on how fast the patches get applied to mainline. Patches are needed for the keyboard quirks, trackpad support, applesmc support and sound support, as usual. On the improvements front, wmpomme has become event-driven, eliminating the fixed-rate update and associated wakeups and visual ugliness in some configurations; pommed has got some code fixes, though nothing major; gpomme has got a new Japanese translation. Hopefully the next release will bring full Late 2008 support.